Embodiments of the present invention relate to policies, and more specifically to techniques for creating business policies.
Businesses often have internal business policies intended to address a wide range of issues such as security, privacy, trade secrets, criminal activity of employees or others with access to the business, and many others. These business policies address various aspects of a business, such as purchasing, selling, marketing, and internal administration. Because of the large number of activities occurring during the course of running a business, which may have various entities located in a variety of geographical locations, it is often impractical to manually monitor all activities in which improper behavior or mistakes may occur.
One approach to implementing business policies has been to monitor and control computer systems used to facilitate a business's activities. For example, information regarding various activities, such as sales and payroll, are often stored in one or more data stores. This information may be analyzed to find activity that might be in violation of a business policy, such as an item on an invoice or paycheck to an employee being outside of a specified range, or a particular employee attempting to access information to which he or she is not entitled access.
Typically, analyzing data requires a high level of technical expertise as the data is often created and stored using a wide variety of business applications which often have differing standards and specifications, are often custom built for specific purposes, and often lack ability to communicate and share information with one another. Consequently, in order to enact business policies, the expertise of those familiar with the business applications to which the business policies are to be implemented is often required. For instance, in order to analyze data stored in a relational database, a person may have to be able to construct a proper SQL statement. Generally, commonly-used applications typically require users to model policies in SQL, PL/SQL, or another application-specific or storage-specific language.
Those making the business policies, however, are often not the same people with detailed knowledge of the business' systems to which the policies are to be applied. For instance, a person or group of people deciding that, to prevent employee fraud, all payments over a specific amount should require approval by an appropriate person, may not have any understanding how invoice data is stored in the business' systems. Such policy makers would prefer to define policies in terms that they understand, such as “user”, “general ledger”, “organization”, etc., and not in terms of the applications with which policies will be implemented, such as “database schema x on host 55.55.55.55”, “FND_USER table”, and “application Y”. Such policy makers would likely prefer not to take the time necessary to learn the specific application terminology as their duties typically do not require such technical expertise.
Moreover, because businesses typically use several different applications to facilitate their activities, it can be burdensome for policy makers to learn specific terminology for several applications. Policy makers would rather prefer that they can use an intuitive interface in order to apply familiar terminology to create policies that may be applied to a variety of applications, without having to create a similar policy for each application.
Previous applications for implementing business policies have included applications that work with specific business applications, and that require users to have an underlying understanding of the technical design of those business applications. One possible reason for this is that database runtimes, which are frequently the underlying runtime for business applications, cannot easily share runtime resources across instances; and most solutions to policy modeling have either used single database instances or single database connections to support their runtime requirements.